Skip to content

fix: materialize artifacts in the user's own temp folder - #947

Merged
wan9chi merged 3 commits into
claude/bump-futures-utilfrom
claude/user-temp-artifacts
Nov 6, 2026
Merged

wan9chi merged 3 commits into
claude/bump-futures-utilfrom
claude/user-temp-artifacts

Conversation

@wan9chi

@wan9chi wan9chi commented Nov 6, 2026 •

Copy link
Copy Markdown
Member

Motivation

vp run writes the fspy preload library and the vt_client_napi addon to the fspy and vt_client_napi folders in the system temp directory. On Linux that directory is /tmp, which every user shares, so those folders belong to whoever ran vp run first. Another user running a different version can't write there, so their tracked tasks fail to start. Running the same version, they use files the first user could replace.

vp run --json, the next PR in this stack, writes its JSON Schema the same way, which is where this came up.

Changes

  • vt_materialized_artifact::user_temp_dir(name) returns a folder in the system temp directory that only the current user can write to:
    • On Unix, {temp}/{name}-{uid}, created with mode 0700. An existing path must be a directory, not a symlink, that the current user owns and that nobody else can write to; otherwise it's an error. On macOS, the temp directory is already per user, so only the folder name changes.
    • On Windows, {temp}\{name}, since the temp directory is already the user's own.
  • fspy and the vt_client_napi addon materialize there.
  • Materialize::at no longer resets the mode of an existing file. That chmod followed symlinks, and with a folder nobody else can write to, there's no drift to fix. Only executables get an explicit mode (0755). Other files keep the 0600 that new temp files get.

🤖 Generated with Claude Code


Note

Medium Risk
Changes where runtime helpers are written and how Unix temp paths are validated, which affects task startup and multi-user safety but is localized to materialization.

Overview
On Linux shared /tmp, fspy and vt_client_napi no longer materialize under world-visible names like /tmp/fspy. They now use user_temp_dir, which on Unix creates {temp}/{name}-{uid} with mode 0700 and rejects symlinks or directories other users can write to; Windows keeps {temp}\{name} because the temp dir is already per-user.

Materialize::at stops chmod-ing existing files (that could follow symlinks); it trusts the user-private directory and only sets 0755 for new executable artifacts, with other new files at 0600. Unit tests cover directory creation and Unix rejection paths. CHANGELOG documents the Linux fix ([#947]).

Reviewed by Cursor Bugbot for commit b498965. Bugbot is set up for automated code reviews on this repo. Configure here.

On Linux, `vp run` wrote the fspy preload library and the
`vt_client_napi` addon to `/tmp/fspy` and `/tmp/vt_client_napi`, which
belong to whoever created them first. Another user running a different
version couldn't write there, and the same version used files the first
user could replace.

- `vt_materialized_artifact::user_temp_dir` returns `{temp}/{name}-{uid}`
  on Unix, created with mode 0o700. An existing path has to be a
  directory, not a symlink, owned by the current user and not writable
  by anyone else. On Windows, the temp folder is already the user's own,
  so it returns `{temp}\{name}`.
- `Materialize::at` no longer reconciles an existing file's mode, which
  followed symlinks: no one else can write to the folder. Only
  executables get an explicit mode, 0o755.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@wan9chi
wan9chi force-pushed the claude/user-temp-artifacts branch from 2c464cf to dd39680 Compare November 6, 2026 01:31
@github-actions

github-actions Bot commented Nov 6, 2026 •

Copy link
Copy Markdown

fspy benchmark

linux

dynamic/launch             change  +0.38%  [ -3.02% ..  +3.08%]  overhead   +54.56%
dynamic/access             change  +0.83%  [ -2.34% ..  +5.36%]  overhead   +21.59%
dynamic/access-relative    change  +0.30%  [ -2.07% ..  +3.06%]  overhead   +70.48%
dynamic/access-contended   change  +0.47%  [ -5.62% ..  +5.33%]  overhead   +34.81%
static/launch              change  +0.46%  [ -3.69% ..  +3.90%]  overhead  +199.51%
static/access              change  -0.20%  [ -0.86% ..  +0.89%]  overhead +1447.75%
static/access-relative     change  +0.62%  [ -0.39% ..  +1.76%]  overhead +1976.00%
static/access-contended    change  +0.48%  [ -0.35% ..  +1.38%]  overhead +2024.52%

macos

dynamic/launch             change  -0.20%  [ -4.60% ..  +4.09%]  overhead  +246.13%
dynamic/access             change  +0.33%  [-22.79% .. +19.16%]  overhead    +1.95%
dynamic/access-relative    change  +0.10%  [ -6.07% ..  +7.72%]  overhead  +225.89%
dynamic/access-contended   change  -3.19%  [-29.63% ..  +5.69%]  overhead    +1.67%

windows

dynamic/launch             change  -0.06%  [ -0.88% ..  +1.27%]  overhead   +30.89%
dynamic/access             change  +0.00%  [ -0.42% ..  +0.21%]  overhead    +1.27%
dynamic/access-relative    change  +0.00%  [ -0.21% ..  +0.62%]  overhead    +1.24%
dynamic/access-contended   change  +0.00%  [ -0.41% ..  +0.61%]  overhead    +1.24%

@socket-security

Copy link
Copy Markdown

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Updatedcargo/​futures-util@​0.3.31 ⏵ 0.3.3410010093100100

View full report

@wan9chi
wan9chi removed this pull request from stack #949 November 6, 2026 02:01
@wan9chi
wan9chi changed the base branch from main to claude/bump-futures-util November 6, 2026 02:01
@wan9chi
wan9chi added this pull request to stack #951 November 6, 2026 02:01
@wan9chi
wan9chi merged commit ead3459 into main Nov 6, 2026
23 checks passed
@wan9chi
wan9chi deleted the claude/user-temp-artifacts branch November 6, 2026 02:21
wan9chi added a commit that referenced this pull request Nov 6, 2026
## Motivation

Shell completion, editor task panels, CI scripts and coding agents need
the workspace's tasks, and how they depend on each other, without
parsing text or loading every `vite.config.*` themselves
(#320, voidzero-dev/vite-plus#2848,
voidzero-dev/vite-plus#1182). [The task graph
RFC](https://github.com/voidzero-dev/vite-task/blob/main/docs/rfcs/task-graph-json.md)
specifies `vp run --json` for this, and this PR implements it.

## Changes

- `vp run --json` prints every package and every task in the workspace,
with each task's `dependsOn` resolved to task IDs. It's indented when
stdout is a terminal and on one line otherwise. A one-element command
array prints as a string.
- Like `vp run` without a task, it loads every package's config, now
that configs load lazily (#944). A broken config in any package fails
the whole command: the error goes to stderr, and nothing goes to stdout.
A `dependsOn` cycle isn't an error.
- `--json` is exclusive, like `--last-details`.
- `$schema`: a test generates `crates/vt/schemas/task-graph.json` from
the document's Rust types with schemars, which is only a dev-dependency,
using the types' doc comments as descriptions. `artifact!` embeds that
file. Each `--json` run copies it to `task-graph_<hash>.json` in the
user's own `vp-schemas` folder in the system temp directory (#947),
unless it's already there, and `$schema` is that file's `file://` URL.
- `vtt pipe-stdout` lets an e2e step snapshot what a command prints when
its stdout isn't a terminal.
- RFC updates:
- `$schema` points to the temp-directory copy rather than to a file in
the vite-plus package.
  - A one-element command prints as a string.
- The task graph is printed even when `dependsOn` entries form a cycle.
  - `--json` loads every config.

Keeping output that a config prints while loading off stdout, which the
RFC requires, is left for later. Only vite-plus's in-process
`vite.config.*` loader can print.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Additive, read-only CLI output path with snapshot coverage; normal `vp
run` execution and caching are unchanged aside from the unrelated
seccomp cast fix.
> 
> **Overview**
> Adds **`vp run --json`**, an exclusive `run` flag (like
`--last-details`) that **does not execute tasks** and instead prints one
JSON document listing every workspace package and task, with each task's
**`dependsOn` resolved to stable task IDs** (`packages/ui#build`, with
`%`/`#` encoded in IDs). Output is **pretty-printed on a TTY** and
**compact on a pipe**; load failures go to **stderr with empty stdout**.
> 
> The JSON includes a **`$schema` `file://` URL** pointing at a draft-07
schema: Rust document types drive serialization, a **unit test
regenerates** `crates/vt/schemas/task-graph.json` via schemars,
`build.rs` embeds it, and each run **materializes** the schema into the
user-scoped temp dir (`vp-schemas`, content-hashed filename) for
editor/agent validation. **`--json` loads every package config**,
matching bare `vp run` task listing (not lazy per-package loading).
> 
> Supporting changes: new **`task_graph_json`** session module, public
**`IndexedTaskGraph::package_graph()`**, optional **`schemars`** on
`vt_str`, test helper **`vtt pipe-stdout`**, plan/e2e snapshots,
RFC/changelog updates, and a **seccomp macro fix** casting syscall
numbers to `libc::c_int` to avoid ambiguous `PartialEq` with serde_json
in the dependency graph.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
914a2ef. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant